The default layout and appearance of interview screens can be changed by editing the screen definitions in Oracle Policy Modeling.
Change the appearance of a control
Show/hide features used for debugging
Improve the appearance and layout of screens
You can change the appearance of text (ie for a question, label or goal) on a question or summary screen using HTML tags defined in your screens file. For example, you may want to make some text bold, or add a hyperlink to a website on your screen.
TIP: In order to use this feature you should have a basic working knowledge of HTML and web development. A good tutorial on HTML can be found at http://www.w3schools.com/html/.
To change the appearance of text using HTML tags:
NOTE: When authoring a rulebase that is to be deployed in the Interview Portlet, relative links to static resources or screens can not be specified using IsHTML and <a href="..." />. This is because portlets require special URL rewriting, which is only available at runtime. Instead, the URL rewriter should be used. Refer to the Oracle Policy Automation Developer's Guide for more information.
Entry of HTML tags in this manner has certain security implications and by default Oracle Policy Modeling and Oracle Web Determinations limit the set of HTML tags that can be entered. The default set of tags allowed are any of the following:
b,i,del,s,div,p,span,pre,table,td,tr,ol,ul,li,blockquote,font,a,h1,h2,h3,h4,h5,h6,img,hr,br
If extra HTML tags are required then they must be added to both Oracle Policy Modeling and Oracle Web Determinations as described below:
The appearance of a control can be customized using Cascading Style Sheet (CSS) classes and styles. For example, you may want to make a control appear with a yellow background. TIP: In order to use this feature you should have a basic working knowledge of CSS. A good tutorial on CSS can be found at http://www.w3schools.com/CSS/.
To change the appearance of a control using CSS class and/or style:
NOTE: CSS Class definitions need support from a web developer in order to work. The web developer will need to modify the CSS and/or Velocity templates for that control type to give controls with that Class their distinct appearance. Bear in mind that the default Oracle Web Determinations (OWD) user interface has a number of accessibility features (for more information, see Accessibility features in OWD). You will need to perform your own checks to ensure that your modifications do not compromise the accessibility of your application. For more information on the development of custom controls, refer to the Oracle Policy Automation Developer's Guide.
For text attributes that are being collected using a text box (ie by selecting an Input Type of Default), you can specify the number of lines for the text box. To do this:
To include an image on a screen you can use add it as a HTML link on a screen control as follows:
<img src="../../../../images/<file>"> (the format for adding images to question screens)
For example, <img src="../../../../images/button.jpg">
There are several features that may be useful to display in Web Determinations while debugging. These settings are made in the appearance.properties file that is located in \Release\web-determinations\WEB-INF\classes\configuration for the project. This file can be opened, modified and saved using Notepad.
TIP: Properties in this file can be overridden on a per-locale basis by creating an appearance.<locale>.properties file (eg appearance.en-GB.properties) file.
By default, attribute ids are not shown in Web Determinations. To enable this feature, change the show-attribute-question-identifiers setting to true. Attribute ids (either the automatically generated id or the public name) will then be displayed before the question text:
By default, a status bar is shown in the top right area of Web Determinations that shows the name of the rulebase, the locale, the user id, and the case id (for saved cases) for the current session:
To improve the appearance and user experience of your screens, follow these tips:
Placing a large number of attributes on one screen, particularly where the user is required to scroll down the screen before continuing, can make system confusing and difficult to use. Generally, each screen should contain a maximum of 4 questions. However, more questions per screen are acceptable where the questions are simple and take less than one line (eg Title, Forename, Surname, Date of Birth, Address), or if you are collecting a group of related questions which will all be defaulted (eg asking about a set of uncommon exceptions).
Web Determinations uses the screen name defined in Oracle Policy Modeling as the first heading on the screen. Additional headings are an important mechanism for conveying meaning about the screen. Variable substitution, eg %Claimant_name_age%, may be used in headings. Headings can be a useful tool to identify factors that will have a significant impact on the course of an investigation. The following are recommended uses for each of the heading levels:
Generally, unrelated questions should not be placed on a screen together. It is much easier to focus on one issue at a time rather than on many different ones.Think about when a question will most naturally be asked in the screen flow. In particular, try to avoid splitting similar concepts.
Visibility attributes should be used on the summary screen so that key outcomes, warnings and links to document generation are only displayed when an attribute proved by a system rule (such as "the investigation is complete") is true or partially true.
Visibility attributes can be used on question screens to hide mutually exclusive attributes. For example, if you want one question to be asked if the person is single and another if they are a member of a couple, or if you want to hide a question where a person is not in a couple. For attributes which are mutually exclusive, you need to be sure that the visibility attribute will be known prior to hitting the screen.
The general rule for attributes which might be proven with shortcut rules prior to hitting a screen is that the attribute should not be shown if it is already known. There will be some exceptions to this:
You may want to group questions on screens where answers to some questions are only required if another question on screen has been answered in a particular way. For example you may only require information on the child’s school if the child goes to school. Both "does the child go to school?" and "what is the name of the child’s school?" can be collected on the same screen, separated by an "If so…" label.
Questions following an "if so…" or "if not…" label should always be defaulted to uncertain. A validation event rule should be used to force the user to answer the question when required.
Shortcut rules should only be used when you can prove a base level attribute before it is asked. If two attributes can be linked by a shortcut rule, then they should generally not be collected on the same screen. If you do have to collect them on the same screen and they are both mandatory the shortcut rule should be removed. You may need to add some validation rules (events) to ensure logical consistency.